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(57) Abstract: A node NI has a protocol stack (10), between appli- 
cation (13) and management (11) layers, and two or more Link level 
interfaces (12, 14) to network links (31, 32). Protocol stack (10) has 
a multiple data link interface (101), which may duplicate packets at 
transmission, to be sent through links (3 1, 32), respecitvely. A mem- 
ory area is reserved. At reception, an idnetifier (X) is calculated for 
each incoming packet e.g. form its IP header, and is searched in at 
least a portion of the reserved memory area; if X is not found (or 
not found for the source node), the packet identifier (X) is stored in 
a currently reserved portion of the memory area. 
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Filtering redundant packets in computer network equipments 

This invention relates to network equipments, as used for example in telecommunication 
systems. 

In such equipments, computer stations or nodes are interconnected through a network medium 
or link. The link may have to be at least partially duplicated to meet reliability constraints. This 
is called link redundancy. It is now assumed by way of example that data are exchanged 
between the nodes in the form of packets. Considering a given packet sent from a source node 
to a destination node, redundancy means that two or more copies of that packet are sent to the 
destination node through two or more different networks, respectively . The copies of the packet 
will usually reach the destination node at different times. Thus, a first one of the packet copies 
is normally processed in the destination node; when arriving, the other copy or copies 
("redundant packets") will be processed in a manner which may depend e.g. upon the transport 
protocol and/or the user application. 

The known Transmission Control Protocol (TCP) has a built-in capability to suppress redundant 
packets. However, this built-in capability involves potentially long and unpredictable delays. 
On another hand, the known User Datagram Protocol (UDP) has no such capability; in this case, 
suppressing redundant packets is a task for user applications. 

A general aim of the present invention is to provide advances with respect to such mechanisms. 

In a first aspect, this invention offers redundant packet filtering software code, comprising code 
for defining: 

- a memory manager, having a reserved memory area, in which it defines a currently designated 
portion of memory, and 

- an incoming packet manager, responsive to an incoming packet for: 

* determining an identifier (X) from information contained in the incoming packet, 

* searching the identifier (X) in at least a portion of the reserved memory area, 

* if a first condition related to the search is met, storing the identifier (X) in the 
currently designated portion of memory, and 
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In both cases, as it will be seen: 



25 



30 



T^ta, afco cove re a node, . protW)1 slack> ^ . 

tocuo,., aod/or devejopme.,, ,„ u described heretaafter. 
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- figure 1 is a general diagram of a telecommunication network system, as an exemplary context 
in which this invention may be applicable; 

- figure 2 shows a group of stations or nodes interconnected through two different links; 

- figure 3 is an exemplary block diagram of a computer station or node, incorporating an 
exemplary embodiment of this invention; 

- figure 4 shows an exemplary format of an IP header in a packet; 

- figure 5 shows a flow chart of a packet transmission in redundant mode; 



- figure 6 shows the initial reception of redundant packets; 



15 - figure 7 shows the structure of an exemplary software module used in this invention; 

- figure 8 is a general flow-chart of the discrimination of received packets; 

- figure 9 shows an exemplary detailed embodiment of operation 640 in figure 8; 

20 

- figure 10 is an exemplary memory arrangement, for implementing this invention; 

- figure 11 shows an exemplary detailed embodiment of operation 650 in figure 8; and 

25 - figure 12 shows an exemplary detailed embodiment of operation 670 in figure 8. 

As they may be cited in this specification, Sun, Sun Microsystems, Solaris, ChorusOS are 
trademarks of Sun Microsystems, Inc. SPARC is a trademark of SPARC International, Inc. 

30 This patent document may contain material which is subject to copyright protection. The 

copyright owner has no objection to the facsimile reproduction by anyone of the patent 
document or the patent disclosure, as it appears in the Patent and Trademark Office patent file 
or records, but otherwise reserves all copyright and/or author's rights whatsoever. 
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other channels may be also used, e.g. heterogeneous networks. In a purely exemplary 
embodiment, links 31 and 32 are arranged as Ethernet physical networks. 

Figure 3 shows an exemplary node Ni, in which the invention may be applied. Node Ni 
5 comprises, from top to bottom, applications 13, management layer 11, network protocol stack 

10, and link level interfaces 12 and 14, respectively interacting with network links 31 and 32 
(also shown in figure 2). Node Ni may be part of a local or global network; in the foregoing 
exemplary description, the network is Internet, by way of example only. It is assumed that each 
node may be uniquely defined by a portion of its Internet address. Accordingly, as used 
10 hereinafter, "Internet address'' or "IP address" means an address uniquely designating a node 

in the network being considered (e.g. a cluster), whichever network protocol is being used. 
Although Internet is presently convenient, no restriction to Internet is intended. 

Thus, in the example, network protocol stack 10 comprises: 
15 - an Internet interface 100, having conventional Internet protocol (IP) functions 102, and a 

multiple data link interface 101, 

- above Internet interface 100, message protocol processing functions, e.g. an UDP function 104 
and/or a TCP function 106. 

20 Network protocol stack 10 is interconnected with the physical networks through first and second 

link level interfaces 12 and 14, respectively. These are in turn connected to first and second 
network channels 31 and 32, via couplings LI and L2, respectively. More than two channels 
may be provided, enabling to work on more than two copies of a packet. 

25 Link level interface 12 has an Internet address <IPJ2> and a Link level address < <LLJ2> >. 

Incidentally, the doubled triangular brackets (« ... ») are used only to distinguish link level 
addresses from Internet addresses. Similarly, Link level interface 14 has an an Internet address 
<IP14> and a Link level address < <LLJ.4> >. In a specific embodiment, where the physical 
network is Ethernet-based, interfaces 12 and 14 are Ethernet interfaces, and «LLJ2» and 

30 «LL 14» are Ethernet addresses. 
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IP functions 102 comprise encapsulating a message coming from upper layers 104 or 106 into 
a suitable IP packet format, and, conversely, de-encapsulating a received packet before 
delivering the message it contains to upper layer 104 or 106. 

In redundant operation, the interconnection between IP layer 102 and link level interfaces 12 
andl4occursthroughmu^ 

has an IP address <IPJ0>, which is the node address in a packet sent from source node Ni. 

References to Internet and Ethernet are exemplary, and other protocols may be used as well 
both m stack 10, including multiple data link interface 101, and/or in link level interfaces 12 
and 14. 



Furthermore, where no redundancy is required, IP layer 102 may directly exchange messages 
with anyone of interfaces 12,14, thus by-passing multiple data link interface 101. 

Now, when circulating on any of links 31 and 32, a packet may have several layers of headers 
in its frame: for example, a packet may have, encapsulated within each other, a transport 
protocol header, an IP header, and a link level header. 

As shown in figure 4, an exemplary IP header may comprise the following fields: 

- a destination IP address 220; 

- a source IP address 221; 

- a header checksum 222; 

- a Time To live (TTL)223; 

- a protocol identifier (IP-PROT) 224; 

- a zone 225 containing fragmentation flags, and fragment offsets (TP-OFF); 

- an IP identification (IP-ID) 226; 

- an IP total length 227; 

- a type of service (T.O.S.) 228; 

- a Header Length (Internet Header Length) 229; and 

- a version identifier 230. 
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Certain of these fields are defined at the level of network protocol stack 10. For a packet 
corresponding to a complete data message, fields 220, 221, 224 and 226 are sufficient to identify 
the data message. Optionally, a data message may be split into a plurality of fragments, sent 
through different packets. In this case, a packet corresponding to a fragment of a data message 
will have its field 225 completed with an indication of the position of the fragment in the data 
message. 

The other fields are mere service fields: for example, field 223 (TTL) determines the time after 
which the packet may be destructed. 

In this specification, "packet header" refers to information attached to a packet, and indicating 
e.g. the source, the destination, and other service information. No restriction is intended to the 
packet header being at the beginning of the packet: it may be at the end as well, or even 
dispersed within the message data. 

The operation of sending a packet Ps in redundant mode will now be described with reference 
to figure 5. 

At 500, network protocol stack 10 of node Ni receives a packet Ps from application layer 13 
through management layer 11. At 502, packet Ps is encapsulated with an IP header, in which: 

- field 220 comprises the address of a destination node, which is e.g. the IP address HM0Q 
of the destination node Nj in the cluster; 

- field 221 comprises the address of the source node, which is e.g. the IP address IP_10(i) of the 
current node Ni. 

Both addresses IP_10(i) and IP_10(j) may be "intra-cluster" addresses, defined within the local 
cluster, e.g. restricted to the portion of a full address which is sufficient to uniquely identify each 
node in the cluster. 

In protocol stack 10, multiple data link interface 101 has data enabling to define two or more 
different link paths for the packet (operation 504). Such data may comprise e.g.: 
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- aroutmg .able, which contain, Wonnalioll enaMtag „ ^ ff ^ ff m 
drfferen, routes (or more) t0 Nj , gotag respecljve|y ^ ^ 
IP_140)ofnodeNj; ~ w 

- « l«e. decision mechanisms, which decide ,he way these routes pass through local 
interfaces IP_12(i) and IP_14(i), respectively; 

- additional an address resoMou protocol (e.g. the ART of Ethernet) may he used to make 
*. correspondence between the IP addresa of a link level interface and its link ,evel (e , 
Ethernet) address. " 5 * 

A, m time, pacta Ps is duplicated into two copies Psl, Ps2 (or more, i, more than two links 
31, 32 are being used). In fact, the copies Psl, Ps2 of packer Ps may be elaborated within 

the packer copies will ne«l to have different encapsulation, or in between. 

A.506,eachcop y P s l > P s2ofpacketPsno „ rraiTOa ^ veMteveiheateOTMi ^ i 
encapsuMon. Each copy of the packet is sen. to a reapecdve one of interfaces 12 and 14 of 
nod. Nt, as determined e.g. b, the above mentioned address resolution protocol. 

In a more detailed exemplary embodiment, multiple data link interface 101 in protocol suck 10 

n.a y prepa K (a«511)afi«packetcopyPsl,havtagmeli„kleveldes.n M ,ionaddressLL12(j) 
and send ,. through e.g. interface 12, having the link level source address LL 12(1). Similarly' 
at 512, another packet copy Ps2 is provided with a link level header containing the link .evei 
desunanon addreas LL_14(j), and sen, thmugh e.g. interface !4, having the link .evel source 
address LL_14(i). 

Ontterea.ptionsid^se^^ 

from the network in node Nj. The first arriving copy is denoted Pal; the other copy or copies 
are denoted Pa2, and also termed "redundant" P acket(s), to reflect the fact they bring no new 
information. 

As shown in figure 6, one copy Pal should arrive through e.g. link level interface 12-j which 
at601,wmde-encapsulateme^ 

pass it to protocol stack 10© at 610. One additional copy Pa2 should also arrive through link 
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level interface 14-j which will de-encapsulate the packet at 602, thereby removing the link level 
header (and address), and pass it also to protocol stack 10(j) at 610. 

Thus, protocol stack 610 normally receives two identical copies of the IP packet Pa, within the 
flow of other packets. This invention will enable (i) discriminating between a first incoming 
packetPal and one or more redundant following packets Pa2, and (ii) filtering the packet data. 
The filtering will depend upon the fact a message is fragmented between several packets or not, 
if such a fragmentation is authorized. Since the ultimate purpose is in most cases filtering, the 
word "filtering", as used here, may encompass both discriminating and filtering. It should 
however be kept in mind that "discriminating" is the basic function. 



It should now be recalled that, amongst various transport internet protocols, the messages may 
use the Transmission Control Protocol (TCP), when passing through function or layer 106; TCP 
has its own capability to suppress redundant packets but with long and unpredictable delays. The 
messages may also use the User Datagram Protocol (UDP), when passing through function or 
layer 104; the User Datagram Protocol relies on application's capability to suppress redundant 
packets, in the case of redundancy, which is also long and resource consuming. 

Incoming packet copies have an IP header according to figure 4. The transport protocol (TCP, 
UDP, or others) being used for a packet is specified in field 224 of the IP header (or, 
alternatively, in a separate transport protocol header). 

This invention may be viewed as providing, at reception side, a filtering function which operates 
independently of the transport internet protocol being used, i.e whether e.g. TCP or UDP in the 
case of Internet, or another protocol. This invention is also compatible with the existing 
transport protocols: the built-in TCP processing of redundant packets may be kept in function; 
in case of UDP, the processing of redundant packets by user applications may also be kept in 
function. 



30 Thus, network protocol stack 10 comprises a filtering function to detect and reject redundant 

packets. The filtering function may be located in multi data link interface 101, or in IP layer 102, 
or in a distinct function module. 
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In accordance win an aspect of this 

uico ; mfomadon !s used ,o b " Ud dis,tac,ive *-«- - - - 

incoming packets. 
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to s.ore the above mentioned distinctive identifiers or •footprtots". 

The "filtering-, tactions 550 will be identifleo for convenience as follows- 

- a. 55!, searcHO is a taction whicb searches for a too*™,, in rbe memory area of 560, o, in 
a part of it; 

- at 552, writeQ is a function which writes a footprint in the memory area; 

- at 553, eraseQ is a function which releases a portion of the memory area; 

- at 555, forward® is a function sending a packet to the upper layers; 

- at 556, delete() is a function deleting or throwing a packet; 

- additionally, if it is desired to process message fragments, a reassembleQ function at 559 
gathers and reorders the fragments before they are forwarded to the upper layers, when the 
message is complete. 

It will be noted that at least functions 551 through 553 interact with memory area 560. 
FigureTalsoshowsanmdependentp^^^ 

purpose is to release some part of memory area 560 from time to time. 
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In fact, the invention may be implemented by using software code, in which memory area 560 
is represented by a memory manager (also denoted 560), capable of cooperating with memory 
hardware existing in the node, to have a reserved memory area, in which it defines at least one 
currently reserved portion of memory. Additionally, incoming packet manager 550 contains at 
least some of the filtering functions 551-559, depending upon the desired implementation. 

The filtering method will be now described with reference to figures 8 and 9. Figures 8 and 9 
show an exemplary detailed embodiment, comprising many features which are optional, i.e. not 
necessary in a simpler embodiment of this invention. 

At 610, an IP packet (Pa) reaches protocol stack 10 of its final destination node Nj. 

Frame 620 in figure 8 contains a set of optional operations, which are of interest when (1) high 
reliability and/or (2) cluster operation are desired. 

Operation 621 checks whether the destination IP address (IP-desi) of the packet Pa matches the 
IP address (IP-mlink) of the multiple data link interface 101 of node Nj. If not, at 622, no 
filtering is made; for example, the packet may be subject to a "normal processing", through 
conventional IP functions 102. Other alternatives of operation 622, may be contemplated, e.g. 
considering a packet whose address does not match IP-mlink is in error. Operations 621 and 622 
may even be omitted, if it is not desired to check the destination address. 

Operation 625 checks whether the source IP address QP-src) of packet Pa matches one of the 
cluster's node IP addresses (IP-orig) as stored in node Nj. In the example, IP-orig is a list 
containing the addresses (e.g. "intra-cluster" addresses) of all the nodes in the cluster. If desired, 
the list may exclude the local node. The list may also be restricted to those of the nodes in the 
cluster which are currently in operation. 

If not, at 626, no filtering is made; for example, the packet may be subject to a "normal 
processing", through conventional IP functions 102. Other alternatives of operation 625 may 
be contemplated, e.g. considering a packet whose address does not match IP-orig is in error. 
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a dtsttncve packet identifier, this value X is called a footprint hereinafter, for shnpfification. 

Generany, whet a pacta is identified as a firs, incoming packet Pal, i.e. footprint X is no, 
ound tn memory area 560 a, 632 (using the searC,, taction), operation 640 ^ ^ 
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is reached. 

the nskthattwo packets Pa being no, redundant with each other have the sanre foohprin, X is 
made as low as desired. 

General (figure 10), memoty area 560 may he organized as one o, mote tables T, in turn 
comprising sub-hahles ST 1 through ST, Parame,er L enables ,o define an order between ,be 

sub-b,bles,or,a,lea s ,,acn n end y m-u S esub. B b 1 e,e.g.STl;p re fe raM ,,anolderoneofte 
tables, e.g. ST. ts also defined, so as to authorize erasure of old footprints, as i, win be seen 
hereinafter. 



: must be 
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560 within the memory area reserved to it. 
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More precisely, a table Ti is dedicated dynamically to a source node Ni (in fact, except Nj), with 
i being an integer varying from 1 to C. C is the number of nodes in the cluster, or, more 
generally, the number of source addresses to be considered. A given source node may have 
several tables Ti. In the example, each table Ti is subdivided into sub-tables STl-i through ST L - 
i. The suffix "-i" is implicit in figure 10 and the sub-tables may be simply designated as ST1 
through ST L hereinafter. 

In a specific embodiment (whether there is a single table T or several tables Ti), the sub-tables 
STm (with m from 1 to L)may be associated with pointers P[n] (with n also from 1 to L), such 
that each pointer P[n] designates a respective one of sub-tables STm. This will be explained in 
greater detail hereinafter. A given value of the pointer, e.g. P[l], designates the currently in-use 
sub-table, e.g. ST L (Figure 10). 

In the first embodiment, the X value as calculated by function F() need only to identify each IP 
packet among packets initiated by source node Ni to destination node Nj. Accordingly, the 
information from the IP header being used to determine the "footprint" does not include the 
source address. 

Thus, for example when the packet is a data message, the value X may be derived from two 
fields of the IP header: field 226 or IP-ID, and field 224 or IP-PROT, e.g. using a concatenation 
of such fields. In a more precisely detailed embodiment, function F() may be a hash function of 
IP-ID and IP-PROT (or of IP-ID only, if a single protocol is being used). 

In this case, the searchQ function of operation 632 is applied with footprint X to determine if 
X already exists in an allocated portion of the memory area, corresponding to node address IP- 
orig of node Ni, i.e. only in table Ti (if it already exists). 

Turning to figure 9, operation 640 of figure 8 may be implemented in detail as follows: 

- operation 641 looks whether a table Ti exists for the source node Ni, known from address IP- 
orig; if not, a table Ti is built at 643, e.g. by memory manager 560. 

- operation 644 checks whether enough space is available for writing X in the current sub-table 
ST1 of Ti; if not, ST1 is expanded at 645; this may be viewed as allocates a new "current" 
portion of memory for node address IP-orig. 
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- then X may be written in the current sub-table ST1 of Ti at 648, and "end" 649 is reached. 

In an embodiment, a given sub-table STm is adapted to store "footprints" of packets coming 
dunng a defined period of time. The term "footprint" designates an unique and single 
identification information about a packet, as described hereinabove. To avoid re-writing sub- 
tables STm, their chronological order may be defined by the pointers P[n]. 

Inaccordancewith^ 

for a hmited time, which is called a critical age CA. When a footprint reaches the critical age 
* may be deleted. The critical age CA may be a multiple of integer L. Thus, the erasure of 
footprints in tables Ti may be based on this discrete period of time CA/L. 

In an embodiment, ^s erasure may be performed by mdependent process 569 (figure 7) named 
e.g. IP-slontuno. This process may be called periodicaUy by the system (or memory manager 
560) to compute a clock, whose tick corresponds to CA/L. Assuming the process has been 
called at instanttl for the first time, then a succession of clock instants W may be defined, as 
shown by equation a. in Exhibit A, beginning with = tl. 

At each such instant t dock , the oldest sub-table or sub-tables STm, as designated by one of the 
pomter values P[n], e.g. PI, is or are cleared, i.e. released for receiving new data. The way the 
pointers P[n] represent the chronological order of sub-tables STm may have different forms. A 
simple form comprises using a cyclic permutation, such that, at each new clock instant W 

- just before that instant, P[l] aims at the currently active sub-tables, while P[L] aims atthe 
oldest sub-tables; 

- at that instant, P[L] is erased, i.e. released for writing; 

- immediately after that, P[l] becomes P[2], P[2] becomes P[3J, ... P[L-1] becomes P[L], and 
P[L] becomes P[l], in accordance with the cyclic permutation, so that the new P[l] (formerly 
P[L]) becomes the currently active memory portion. The new P[L] (formerly P[L-1]), now aims 
at the oldest stored footprints. 

Formally (in this embodiment): 

- if a packet is received within the time interval defined by equation II in Exhibit A, where t 
represents any instant, and its footprint X is not yet stored in the table Ti, this footprint X is 
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stored in the cleared sub-table STm pointed during this time interval by the pointer P[l]. Each 
sub-table STm is only writable during the time interval it is pointed with the pointer P[l]. 

- more generally, at an instant t, sub-tables STm being aimed at by pointers P[n'] designate sub- 
5 tables having received packets within the time interval defined by equation 12 in Exhibit A, n' 

being an integer varying from 2 to L. 

Now, the detailed implementation of operations 650 and 670 of figure 8 may depend upon 
whether the message in the current packet Pa is complete, or, by contrast, is a fragment of a 

10 message being split over several packets. In the example, IP header of a packet Pa, field 225 or 

"IP-OFF" contains indications of the existence of fragments, and of the position of the current 
fragment in the complete message, in the form of fragmentation flags, and fragment offsets. 
Operations 650 and 670 will be described in a version taking fragmentation into account; 
however, the operations directed to fragment processing may be omitted in certain cases, e.g. 

15 depending upon the target system, and the expected level of performance. 

Figure 11 now shows an exemplary implementation of operation 650 of figure 8. Operation 652 
determines whether a first incoming packet having footprint X is a fragment, e.g. from field 225 . 
If not, the packet may be forwarded (function 555) to upper layers at 653. 



20 



The case of a fragmented message will now be considered. 



A fragment queue (FQ(X)) designates a queue of fragments, all having the footprint X, in the 
course of being assembled to obtain a complete data message with the same footprint X. In fact, 

25 the re-assemble() function may be used to receive packets having the same X, and to re-order 

them into a data message, in accordance with the fragment offset data in the field IP-OFF of 
the IP header of each "fragment-containing" packet. This storage task may be devoted to 
memory manager 560, using its memory area (or a separate memory area), or to a separate 
process, again using the memory area of 5 60 or a separate memory area, and interconnected with 

30 multi data link interface 101. 

It should also be kept in mind that the fragments do not necessarily arrive in their native order. 
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Reverting to figure 1 1, operation 654 determines whether there is already a fragment queue for 
X (and To, ,e. the source address ZP-o^g). If not , a fragment is built at 655. At 656 the 
mcommgfragmentis stored at 656, either at a location defined from its field 225 oi"IP-OFF> 
or together with a representation of its location in the complete message, for later re-ordering 
then going to "end" 669. 

Figure 1 1 takes into account the fact that, being a first incoming packet with X, fragment Pal 
cannot already exist in the fragment queue. 

Now, Figure 12 shows an exemplary implementation of operation 670 of figure 8 for a packet 
Pa2, i.e. a packet which is not the first incoming one with footprint X. 



Operation672determmeswhemerapacketPa2havmgfootprintXisafragment,e.g.fromfield 
225. If not, the packet may be thrown or deleted (function 556) at 673, and "end" 699 is 
I 5 reached. 



The case when Pa2 is a fragment shall now be considered. 



NormaUy,afragmentqueue already exists for X and Ti. However, if high reliability is desired, 
the existence of a fragment queue may be checked at 675 (the dashed line box illustrates the 
opuonal character of this). The operations in 675 may be similar to 654 and 655 in figure 11. 

Then, operation 680 checks whether Pa2 is already present in fragment queue FQ(X). In the 
fragments have been immediately ordered, this may be made by determining whether the 
content at the fragment offset of Pa2 is occupied (and is Pa2, if desired); if the fragment offsets 
are stored in FQ(X) with the packets, this may be made by looking for the fragment offset of 
Pa2 amongst the fragment offset having already been stored. 

If Pa2 is already present in fragment queue FQ(X), it may be thrown at 683, and "end" 699 is 
30 reached. 



Otherwise, packet Pa2 is added to fragment queue FQ(X), at its location and/or together with 
a representation of its location, as previously. 
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Now, operation 686 checks whether the fragment queue is complete, again using the current 
and/or stored fragmentation data. If not, "end" 699 is reached. Otherwise, operation 687 may 
forward the complete message contained in FQ(X) to the upper layers. At 688, the memory for 
FQ(X) may be immediately released. Alternatively, it may be released at a later stage. It may 
5 be found interesting to release FQ(X) at the same time as X is released by the above mentioned 

IP-slowtimo process. Then, "end" 699 is reached. 



If desired, the "fragment processing" operations in figures 11 and 12 may be merged into a 
single process, which is called when a fragment is detected in either case. 



10 



In an embodiment, the function F() may comprise a so-called hash function H, which spreads 
packets as uniformly as possible in a table Ti, e.g. Tl-1. Such a hash function indicates at any 
instant if the sub-table STm pointed with the pointer P[l], is full or not. If the corresponding 
sub-table STm is full, the table Tl-1 is considered to be full and the function H has to allocate 
15 a new table, e.g. Tl-2, to store packet footprints in a sub-table STm designated with the pointer 

P[l] during a given time interval CA/L. This new table is allocated between certain not 
allocated reserved tables in memory area. 

In other words, this new table Tl-2 provides an additional storage space to filter packets coming 
20 from the same source node as table Tl-1. When the function H determines that tables Tl-1 and 

Tl-2 have full sub-tables STm, an other new table may be added, e.g. Tl-3. Each of these tables 
store footprints of packets coming from the same given source node, in the example. 

Another optional task is to release tables without footprint in any of their sub-tables. In an 
25 embodiment, the process called IP-slowtimo further has to detect, at each CA/L, allocated tables 

whose each sub-table has no footprint. These tables are then released and considered not to be 
allocated any more, i.e. freed to be allocated again. 

The above described method and system elements enable a fast discrimination and filtering of 
30 redundant packets, while taking into account fragmented messages, if desired. This is due inter 

alia to the dynamic allocation of memory portions within the whole memory area being 
allocated to memory manager 560. 
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As above described together with its alteratives, the first embodiment of this invention has 
advantages where messages are exchanged frequently between a restricted number of stations 
eg. wrttan the nodes of a cluster, in fields like communications, business, government, 
education, entertainment, for example. 

However, this invention is not limited to the hereinabove described features. 

In a second embodiment, packets coming from several source addresses might be stored 
commonly in the same portion of memory, i.e. in a single table T. If so, the footprint function 
F0 should be supplemented to take the source address into consideration. In this case the 
searchQ function of operation 632 in figure 8 would explore all allocated portions of the 
memory area, or even the whole memory area. 

In this second embodiment, operations 641 and 642 of figure 9 may be changed, or even 
omitted, to the extent one or more packets coming from another source address have already 
caused a table T (more broadly, a memory portion) to be allocated, and written with the X 
values of these previous packets. In fact, if all incoming packets are stored in common in the 
whole memory area, there may be no need to implement operations 641 and 642. 



In an alternative of the second embodiment, it may also be contemplated that tables Ti are 
dedicated to groups of source nodes, instead of individual source nodes. If so, the footprint 
function F0 should be supplemented to take the source address into consideration, at least 
partially. 

25 Atodembodtaentoft Ws*^ 

processing of fragment packets. In this case, the value X takes into account the fragment 
identifying data, at least in part. For example, the value X may be defined from a concatenation 
of the value IP-ID, IP-PROT, and IP-OFF of the IP header (and also IP-orig, if a single table 
Tis bemgused). m tms (^e, eachfra^ 

30 complete messages. In other words: 

- in the firstly described embodiment, only the first incoming fragment packet is considered as 
Pal;allsubsequentpackets are treated as Pa2,independentlyoftheirfrag m entofeet,andofthe 
fact they are first arrived, or redundant, for their particular offset; 
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- in the third embodiment, an incoming packet is considered as Pal if it is the first arriving for 
its fragment offset; thus, a packet seen as Pa2 is redundant with a previously received packet 
having the same offset. 

In an version of that embodiment, operation 640 in figure 8 may be integrated to the Pal packet 
processing in operation 650. 

In a fourth embodiment of this invention, where a fragment carrying packet is concerned, no 
footprint X (of fragment) is written in memory 560 at operation 640 (figure 8). Thus, only 
footprints of complete message packets are written in memory 560. The fragment carrying 
packets are not be filtered by using the footprint. Instead, all fragments are stored in the 
fragment queue, whether redundant or not. When the message is complete (i.e. all "offsets" are 
present, whether redundant or not), the reassembleQ function gathers the whole message and 
ignores the redundant fragments. In other words, the filtering of fragment packets is made in the 
fragment queue, at the time the reassembleQ function is executed. 

The reassembleO function identifies the identical duplicated fragments with the value X being 
a concatenation of the value IP-ID, IP-PROT, and IP-OFF of the IP header. The reassembleO 
function throws duplicated fragments. Once a fragmented data message is reassembled, the 
fragment queue is freed and the complete data message is forwarded to upper layer. 
Those skilled in the art will note that any subsequently arriving fragment packets, being 
redundant with the just completed message, will create a new fragment queue, which is not 
useful. 

In an alternative of the fourth embodiment, where fragment carrying packets are concerned, the 
footprint X is written in memory 560 only after the complete message has been re-assembled. 
In this case, the footprint X need not comprise any fragment identification data. Thus, both 
footprints of complete message packets and of reassembled fragmented data messages are 
written in memory 560. These operations may be added in figure 11, after operation 656. Thus, 
any subsequently arriving fragment packets are filtered. Indeed, after forwarding a reassembled 
fragmented data message and storing its footprint in memory 560, the duplicated fragment 
carrying packets corresponding to this footprint in operation 632, figure 8, are thrown, in 
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operation 670. Thus, no duplicated fragment of a fragmented data message is stored in a new 
fragment queue. 

This invention also covers the software code for performing the method, especially when made 
available on any appropriate computer-readable medium. The expression "computer-readable 
medium" includes a storage medium such as magnetic or optic, as well as a transmission 
medium such as a digital or analog signal. The software code basically includes separately or 
together, the codes defining the memory manager 560, the packet manager 550, and the codes 
for implementing at least partially the flow-charts of figures 5, 6,8 ,9 11 and 12. 
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tdocc = tl+pxCA/L 

5 

II. 

[t-(t-tl)MOD(CA/L), t] 
10 12. 

[t-(t-tl)MOD(CA/L)-(n'-l)xCA/L,t-(t-tl)MOD(CA/L)-(n'-2)xCA/L] 
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Claims 



1. The software code, comprising code for defining: 

- a memory manager (560), having a reserved memory area, in which it defines a currently 
designated portion of memory, and 

- an incoming packet manager (550), responsive to an incoming packet for: 

* determining an identifier (X) from information contained in the incoming packet, 

* searching the identifier (X) in at least a portion of the reserved memory area, 

* if a first condition related to the search is met, storing the identifier (X) in the 
currently designated portion of memory, and 

* if a second condition related to the search is met, filtering out the incoming packet as 
redundant. 

2. The software code of claim 1, wherein: 

- the first condition comprises the identifier (X) being not found, and 

- the second condition comprises the identifier (X) being found. 



3. The software code of claim 1 or claim 2, wherein: 

- the memory manager (560) is capable of defining a fragment memory area (FQ(X)) in its 
20 reserved memory area, and 

- responsive to a third condition, comprising the fact an incoming packet contains a message 
fragment, the incoming packet manager (550) stores at least a portion of the packet in the 
fragment memory area (FQ(X)). 



4. The software code of claim 3, further comprising a mechanism for re-assembling : 
when all its fragments have been stored in the fragment memory area (FQ(X)). 



5. The software code of claim 3, wherein: 

- the identifier (X) is determined from information which includes fragment identifier 
30 information, and 

- the third condition comprises the incoming packet containing a message fragment and its 
identifier being not found. 
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6. The software code of claim 3, wherein: 

- the identifier (X) is determined from information other than fragment identifier information, 

- the first condition comprises the identifier (X) being not found, and 

- the second condition comprises the identifier (X) being found and the incoming packet data 
containing an unfragmented message. 

7. The software code of claim 6, wherein: 

- the first condition comprises the identifier (X) being not found and the incoming packet 
containing an unfragmented message. 



8. The software code as claimed in any of the preceding claims, wherein: 

- the memory manager (560) is capable of defining selected sub-areas (Ti; Tl-1) in the reserved 
memory area, and of defining a selected currently designated portion of memory in each such 
selected sub-area, 

15 - the identifier (X) is determined from information in the packet other than source-related 

information, 

- the incoming packet manager (550) performs the search is a selected sub-area associated to the 
source address of the incoming packet, if any, and 

- if the first condition related to the search is met, the identifier (X) is stored in a currently 
20 designated portion of memory of a selected sub-area associated to the source address of the 

incoming packet. 

9. The software code as claimed in any of the preceding claims, farther comprising a monitoring 
timer mechanism (569), capable of releasing areas in the reserved memory which contain older 

25 identifiers (X). 

10. The software code of claim 9, wherein: 

- the memory manager (560) keeps a chronological track of prior designated portions of 
memory, and 

30 - the monitoring timer (569) periodically orders the memory manager (560) to release oldest 

ones of the designated portions of memory. 
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11. The software code as claimed in any of the preceding claims, wherein the memory manager 
(560) comprises a hash function for storing data in the reserved memory area. 

12. Thesoftwarec»deasc^ 

(560) is arranged to assign an additional currently designated portion of memory (Tl-2), when 
a currently designated portion of memory (Tl-1) is full. 

13. The software code as claimed in any of the preceding claims, wherein the first and second 
conditions each comprise the destination address of the incoming packet matching a proper 

10 address (IP_10). 

14. A method of processing redundant packets, comprising the steps of: 

a. determining an identifier (X) from information contained in an incoming packet (630), 

b. searching the identifier (X)in at least a portion of a reserved memory area (560), and ' 
c processing the packet, the processing comprising: 

cl. if a first condition related to the search is met, storing the identifier (X) 
currently designated portion of the reserved memory area, and 



15 



20 



25 



30 



in a 



c2. if a second condition related to the search is met, filtering out the incoming 
packet as redundant. 



15. The method of claim 14, wherein: 

- the first condition comprises the identifier (X) being not found, and 

- the second condition comprises the identifier (X) being found. 

16. The method of claim 14 or claim 15, wherein step c. further comprises: 

c3. responsive to a third condition, comprising the fact an incoming packet contains 
a message fragment, storing at least a portion of the packet in a fragment 
memory area (FQ(X)). 

17. The method of claim 16, wherein step c. further comprises: 

c4. . re-assemblingamessagewhenaUitsfragmentshavebeenstoredin the fragment 
memory area (FQ(X)). 
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18. The method of claim 16, wherein: 

- step a. comprises determining the identifier (X) from information which includes fragment 
identifier information, and 

- the third condition of step c3. comprises the incoming packet containing a message fragment 
and its identifier (X) being not found. 



19. The method of claim 16, wherein: 

- step a. comprises determining the identifier (X) from information other than fragment 
identifier information, 

10 - the first condition of step cl. comprises the identifier (X) being not found at step b., and 

- the second condition of step c2. comprises the identifier (X) being found at step b. and the 
incoming packet data containing an unfragmented message. 

20. The method of claim 19, wherein: 

15 - the first condition of step cl. comprises the identifier (X) being not found at step b. and the 

incoming packet containing an unfragmented message. 

21. The method as claimed in any of claims 14 through 20, wherein: 

- step a. comprises determining the identifier (X) is determined from information other than 
20 source-related information, 

- step b. comprises searching the identifier (X) in a selected sub-portion, if any, which is 
associated to the source address of the incoming packet, and 

- step cl. comprises: if the first condition related to the search is met, storing the identifier (X) 
in a currently designated sub-portion of the reserved memory area, which is associated to the 

25 source address of the incoming packet. 

22. The method as claimed in any of claims 14 through 21, further comprising the step of: 

d. at time intervals, releasing areas in the reserved memory which contain older identifiers 
(X). 



30 



23. The method of claim 22, wherein step d. comprises: 

dl. keeping a chronological track of prior designated portions of memory, and 
d2. periodically releasing oldest ones of the designated portions of memory. 
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24. The method as claimed in any of claims 14 through 23, wherein step c. comprises using a 
hash function for storing data in the reserved memory area. 

25. The method as claimed in any of claims 14 through M24, wherein: 

5 - step cl. comprises using an additional currently designated portion of memory (Tl-2), when 

a currently designated portion of memory (Tl-1) is full. 

26. The method as claimed in any of claims 14 through 25, wherein the first and second 
conditions each comprise the destination address of the incoming packet matching a proper 

10 address (EP_10). 

27. In a node having a protocol stack (10), a multiple data link interface (110), capable of at 
least partially implementing the functions in the method of any of claims 14 through 26. 



15 



28. A cluster having a plurality of nodes interconnected through a redundant link, in which at 
least two of the nodes are arranged for implementing the functions in the method of any of 
claims 14 through 26. 
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